1. Field of the Invention
The invention relates to an extended multicast information broadcasting method, a system and corresponding software products.
2. Description of Related Art
At the present time, businesses or industrial or commercial companies are virtually compelled to transfer data and information supported by this data via the IP network.
Most commonly, these businesses or companies are multi-establishment entities, with one or more establishments normally being associated with at least one website, these sites being interlinked via an IP network. These businesses or companies are therefore also multi-site entities.
As a general rule, the IP multicast information broadcasting process can be used for information broadcasts on each of the abovementioned sites.
However, the abovementioned broadcasts are said to be “private”, because they are limited and restricted to users of fixed or roaming terminals identified as belonging to the site, but cannot in any way be transmitted from one site to another.
This type of broadcast is, for this reason, called a broadcast local to the site.
A review of the unicast and multicast broadcasting techniques is given first of all below, in conjunction with the figures.
With reference to FIG. 1a, the unicast broadcasting technique currently used on the IP network supports point-to-point broadcasts.
A broadcast server SD generates a flow of data to each of the terminals (receivers) R1 to R7, for which it has received a request via routers RO0 to RO10.
The more receivers there are, the more the SD server is polled and the more network bandwidth is used to transmit identical data and information.
In the case of the multicast broadcasting technique, however, with reference to FIGS. 1b and 1c, a receiver, R6, wishing to have access or subscribe to a multicast broadcast sends an access request to its access router RO6, according to the IGMP method (RFC 2236). The access router RO6 uses a multicast routing protocol, the PIM-SM method (RFC 2117) for example, to relay this request to a point in the network (switching point or router) that is already receiving this broadcast, possibly directly to the access router RO0 of the broadcasting source, as is represented in FIG. 1b. The route of the abovementioned request is represented by solid line arrows in FIG. 1b. 
Each router belonging to the path keeps in memory the software interface, the routing address data, via which it has received a request to subscribe to a determined broadcast. When the router concerned receives the IP data packets relating to this broadcast, it transmits them to its adjacent router by reverse path, via the stored software interface.
Thus, the IP data packets corresponding to this broadcast reach the requesting receiver R6 by reverse path. The reverse path is represented by broken line arrows in FIG. 1b. 
When a new receiver, receiver R1 for example as represented in FIG. 1b, wants to access this same broadcast, it sends its access request to its access router RO4. The latter transmits this request until it reaches a router executing the requested broadcast, in this case the router RO2 in FIG. 1b. The path of this request is represented by alternating solid and broken line arrows in FIG. 1b. 
The router that is furthest forward, in the broadcast direction, reached by this request, which is already receiving the broadcast data and information requested by the receiver R1, stops this request from being returned to the broadcasting source, the server SD, duplicates the IP data packets to transmit the latter also to the receiver R1 via the stored software interface, by reverse path. The path of the complete broadcast is represented by broken line arrows in FIG. 1b, the reverse path RO2-RO3-RO4-R1 being represented by double broken line arrows, although belonging to the same multicast broadcast as that requested by the receiver R6. The same applies for any other receiver R2 to R5 likely to request the same broadcast.
Consequently, with the IP multicast broadcasting technique, it can be seen that the server SD sends the data supporting the information forming the broadcast only once. This data is duplicated by the routers of the network dynamically, to reach the authorized receivers that have requested it. The set of routes or paths taken by the IP data packets of the broadcast, from the server SD to these authorized receivers, forms a multicast information broadcast tree, the root of which is the broadcasting source, server SD or root router RO0, the various paths forming the branches and the terminal receivers forming the leaves. It will be understood, in particular, that, following the access request from the receivers R6 and R1, in the case of an access request from the receiver R4, the branch RO2-RO9 and receiver leaf R4 are added whereas in the case of an access request from the receiver R2, only the receiver leaf R2 is added.
Regarding the IP multicast addressing, the multicast broadcasting technique introduces the concept of multicast broadcast. An IP data packet that is part of a multicast broadcast has a destination IP address, called a multicast address. All the data packets supporting information belonging to one and the same broadcast have the same destination multicast address. Whereas a unicast IP address is used to identify only a single receiving machine or terminal, a multicast IP address is used to identify a set or group of machines, the set of authorized machines with access to this broadcast. A multicast address is therefore always a destination address and is pointless as a source address. To this end, a portion of the IP address codes is reserved for the assignment of multicast addresses.
Specifically, the RFC 2365 standard (Administratively Scoped IP Multicast) defines a way of assigning to certain multicast addresses an administrative limit on the broadcast that these addresses represent.
Depending on the value of the multicast address assigned to a broadcast, this broadcast is consequently intended to be limited:                to a site (“site-local scope”);        to an organization (“organization-local scope”);        to the entire Internet (“global scope”).        
The data supporting an information broadcast limited to a site, “site-local scope”, must not cross the administrative limits that are imposed on it by its multicast address. To this end, each administrative entity is responsible for the configuration of its routers so as to handle the translation, in terms of network configuration on this site, of above-mentioned administrative rules and compliance with the latter.
The possibilities offered by the above-mentioned multicast broadcast concept with a view to the broadcasting of data to the different sites of a multi-site business or entity at the present time appear to be substantially limited.
If, with reference to FIG. 1c, we assume a multi-site entity located on four separate sites, site 1, site 2, site 3 and site 4, site 1 for example including a multicast broadcast server SD, such a broadcast, according to a “site-local scope” mode, is local to the site 1. Consequently, the IP data packets supporting the information of this broadcast are not transmitted outside the site. These data packets do not therefore pass through the interconnecting network and cannot be received by the users of the other sites, site 2, site 3, site 4.
One possibility could be, where appropriate, to implement a unicast IP tunnel between the site 1, the originating site, and each of the users, in particular the roaming users connected to the other sites, site 2, site 3 and site 4.
Although an appropriate signaling can be used to allow the routing of requests to access the broadcast, respectively of the data packets supporting the information of this broadcast by reverse path via each of the unicast IP tunnels, the drawbacks generated by such a solution are as follows:                loss of all the benefits associated with the multicast broadcast over the network interconnecting the sites, precisely because of the creation of substitute unicast IP tunnels;        scaling problem: the more requesting users there are, the more it is necessary to create unicast tunnels, and the more, consequently, the access router RO0 of the site 1 has to duplicate the IP packets supporting the information of the broadcast and the more the bandwidth on the interconnecting network is used to transmit the same data packets multiple times. Such a method is therefore analyzed, from the point of view of the bandwidth consumption of the connecting network, as a simple multiplication of point-to-point connections, which consequently limits the number of simultaneous requesting users on all the sites of the multi-site entity.        